home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group94b.txt / 000116_icon-group-sender _Mon Nov 21 01:07:51 1994.msg < prev    next >
Internet Message Format  |  1995-02-09  |  1KB
  1. Received: by cheltenham.cs.arizona.edu; Mon, 21 Nov 1994 00:08:04 MST
  2. Date: Mon, 21 Nov 1994 01:07:51 +0600
  3. From: jeffery@runner.jpl.utsa.edu (Clinton L. Jeffery)
  4. Message-Id: <9411210707.AA09975@runner.utsa.edu>
  5. To: ruiter@ruls41.fsw.LeidenUniv.nl
  6. Cc: icon-group@cs.arizona.edu
  7. In-Reply-To: <3aofof$f5m@highway.LeidenUniv.nl> (ruiter@ruls41.fsw.LeidenUniv.nl)
  8. Subject: Re: optional typing in Icon (longish)
  9. Content-Length: 973
  10. Errors-To: icon-group-errors@cs.arizona.edu
  11.  
  12.  
  13. > Jan Peter de Ruiter suggests we add optional type declarations to Icon...
  14.  
  15. The Icon implementation book contains much useful material based on the Icon
  16. version 6.0 translator/interpreter system (icont), but it does not report on
  17. the last 7-8 years' of work on Icon.  The Icon compiler (iconc) does type
  18. inferencing and determines a precise type for over 90% of the uses of
  19. variables.  It produces code that skips run-time checks when they are not
  20. needed.  Your suggestion would speed up the Icon interpreter somewhat, but
  21. would not help the Icon compiler much.
  22.  
  23. I think optional type declarations are a good idea anyhow, because in larger
  24. (multiperson) projects, they would serve as documentation and as an
  25. assertion that the Icon compiler could verify during type inferencing.
  26. Unfortunately, there are presently no resources to pursue this kind of
  27. effort, so your options are: write your own, or form a group that will
  28. support these kinds of additions to the language.